Technical Questions
Volume Number: 1
Issue Number: 11
Column Tag: Ask Prof. Mac
Technical Questions Answered
By Steve Brecher, Software Supply, MacTutor Contributing Editor
[Prof. Mac is dedicated to helping you solve your Macintosh Programming
problems. Each month Prof. Mac will research out your problem and print the best
possible solution in MacTutor. Don't waste time in frustration! Send your technical
questions to Prof. Mac and let him research your problem for you. Write to Prof. Mac,
care of this Journal. -Ed.]
Coordinate Systems
Q. Moving a window by using MoveWindow(..., , , ...) doesn't work. What do I need to do? A. The coordinates you pass to MoveWindow must be global coordinates, so
transform them with calls to LocalToGlobal first. The distinction between local and
global coordinates can be confusing (it was to me, anyway), so let's discuss coordinate
systems.
A coordinate system is an abstraction. I visualize it as an infinitely large sheet of
graph paper with one intersection of grid lines designated 0,0. By assigning one grid
intersection (0,0 or any other ) to a specific bit in memory, we thereby are able to
refer to pixels (memory bits) in terms of coordinates rather than in terms of RAM
addresses. This is very convenient when thinking about graphics.
The QuickDraw bitmap is what associates a particlar coordinate system (graph
paper) with a particular set of memory locations.
Think of the sheet of graph paper thumbtacked to a bit in memory. The
thumbtack goes through the graph paper at the intersection designated by the top, left
coordinates of the bitmap's bounds rectangle; this can be any intersection at all -- it
needn't be 0,0. The tack's point sticks into memory at the location designated by the
bitmap's baseAddr.
A point expressed in local coordinates is merely one that has been thus assigned to
a pixel as specified by the relevant grafPort's bitmap. Each and every coordinate found
in a grafPort (in the sense of a field in a Pascal record) is, by definition, local to that
grafPort.
When we wish to compare the locations with respect to memory (screen) of
points in two different grafPorts, we must adjust their coordinate systems so that the
same intersection on each port's graph paper is assigned ("thumbtacked") to the same
pixel. The convention for doing this is to "move" each graph paper so that its 0,0
coordinate is at the lowest-addressed pixel. Note that this method of inter-port
comparison works only if both lowest-addressed pixels (baseAddr's) are the same!
This implied requirement -- satisfied, of course, if both baseAddr's are equal to
screenBase -- is usually taken for granted in IM discussions.
A local coordinate is an expression of vertical and horizontal distance from the
0,0 intersection on the particular piece of graph paper associated with a grafPort. A
global coordinate is an expression of vertical and horizontal distance from the baseAddr
pixel. If (and only if) two ports have the same baseAddr, then global coordinates from
each may be compared and yield a valid graphics relationship.
While the QuickDraw chapter of Inside Macintosh says (of two ports being
compared) "using the same bit image (such as the screen)", the rest of IM when using
the term "global" takes for granted that the screen is in fact the common bit image for
both ports.
When IM says a document being drawn "sticks to the coordinate system," I
mentally translate that to "sticks to the graph paper"; similarly, I mentally translate
"sticks to the screen" to "sticks to memory.
Of course, the memory locations designated by a bitmap do not have to coincide
with the memory from which the screen is displayed. Drawing merely affects the
memory designated by the bitmap; if that memory is (all or partially) in the screen
buffer, then the screen display will be affected.
QuickDraw Regions Limitation
Q. L. Tannenbaum of Long Beach, CA, submitted some MacFORTH code that
illustrates a problem with QuickDraw's handling of complex regions. His program
created 17 vertically-oriented rectangles while defining a region. Subsequently
FrameRgn didn't seem to work correctly. He wants to know if the problem is in his
code or in QuickDraw.
A. By doing some experiments ,and with the help of MacsBug, I analyzed the
problem as follows.
There is a problem in QuickDraw's handling of regions containing more than 12
vertical (higher than wide) rectangles. FrameRgn of a region containing more than 12
vertical rectangles will paint them instead of frame them, and rectangles after the
12th (from left to right) will be enlarged horizonally.
If there are more than 24 such Rectangles, FrameRgn will crash with an address
error.
The problem seems to be due to the way region information is stored, in
conjunction with the fact that some routines (e.g., FrameRgn, possibly as a part of code
common to other routines) allocate a fixed amount of space on the stack which is not
large enough to accommodate a chunk of information recorded for the region.
For (at least) multiple rectangles, region information is stored in chunks
consisting of pairs of arrays of coordinates in the form
top[i] left[1] right[1] left[2] right[2] ... left[n]
right[n]
bottom[i] left[1] right[1] left[2] right[2] ... left[n] right[n]
where i ranges over 1 to the number of horizontal lines on which the rectangle corners
lie, from top to bottom of the grafPort's portrect. Each array is terminated with a
$7FFF marker.
For horizontally-oriented rectangles, n=1, and each array contains exactly 3
coordinates. For vertically-oriented rectangles, n is equal to the number of
rectangles, and each array is therefore potentially large. QuickDraw appears to do a
Link A6,#-562, and part of the stack frame thus allocated appears to be filled with a
chunk of coordinates via autoincremented A2 as the destination address of a move loop.
If the chunk is too large, stack frame underflow will result.
I submitted the above to Apple's Tech Support team, and Ginger Jernigan replied:
"It isn't a bug, it is a limitation in QuickDraw, which will be documented in the
final version of Inside Macintosh. Your analysis of the situation was correct. We're
working to fix it or at least alleviate the nasty problems that occur (like getting real
syserrors from Quickdraw calls).
Boldly Outlining Buttons
Q. Mike Scanlin asks: how do you get the thick border to outline a button in a
dialog box for the button representing the default if the user hits Return (usually
either "OK" or "Cancel")?
A. Usually such button highlighting appears in alert boxes. The Dialog Manager
automatically highlights either item 1 or item 2 in an alert box. Whether item 1 or
item 2 is highlighted depends on the value of a bit in the "stages" word for the current
stage of the alert. (See Inside Macintosh, Dialog Manager, pp. 34-36.)
The stages word is located in the ALRT resource, and is divided into four 4-bit
parts, each part governing one stage, or consecutive occurrence, of the alert. One bit
in each part governs item highlighting; if the bit is clear, item 1 is highlighted, and if
it's set, item 2 is highlighted.
Often item 1 is an "OK" button and item 2 is a "Cancel" button, and IM assumes
this in its illustration. But in fact the Dialog Manager will highlight item 1 or item 2
regardless of what kind of item it is. This can somethimes be a problem. For example,
if you have an alert with only a message (a statText item) and an "OK" button, you don't
want any highlighting. But the Dialog Manager will relentlessly highlight either item
1 or item 2; if the statText is item 2 and the appropriate bit in the stages word is set,
the text will have an ugly bold round-corner rectangle drawn around it. If the bit is
clear, the "OK" button will be highlighted, which would be silly since it's the only
enabled item.
The only way to handle such a situation is to add a dummy item to the alert's item
list (such as a one-character statText item located outside of the alert's rectangle) and
let that dummy item "take" the highlighting. In our example, the dummy item could be
item 1, and the bits in the stages word would be clear so that item 1 is highlighted. To
see an example of this technique, use ResEdit to examine the Finder's DITL 129
resource.
To highlight a button in a dialog that is not an alert, you can use a userItem.
Usually a userItem just draws a non-standard item, such as a picture. In this case, we
can employ a userItem to change the appearance of another item -- namely, of our
button.
A userItem consists of a procedure, as documented in IM, Dialog Manager, p. 11.
We will ignore the itemNo parameter, since the item that the userItem will be
operating on is not the userItem itself, but the button we want to outline. The
QuickDraw techniques for boldly outlining a button are shown on p. 13 of the Dialog
Manager section:
PenSize(3,3);
InsetRect(displayRect,-4,-4);
FrameRoundRect(displayRect,16,16)
--where displayRect is the button's display rectangle; GetDItem can be used to obtain
it.
Q. Paul Cozza of Long Beach, CA, asks: two undocumented Printing Manager
routines -- PRSTLINIT and PRJOBINIT -- were mentioned on p. 32 of the First Draft
(6/11/84) of Printing Manager section of Inside Macintosh. Apple promised
documentation in a later release of the manual, but the routines have mysteriously
disappeared altogether from the latest version (Second Draft, 3/27/85, distributed
with the May 1985 Software Supplement). If these routines are now unavailable,
what is the way to modify the print style and job dialogs?
A. My guess is that the routines succumbed to the generalization of printing
procedures that was necessitated by the advent of the Laserwriter.
In the Imagewriter file (I'll let you know about the Laserwriter as soon as I can
afford one!), the style dialog is the DLOG -8192 resource, and the job dialog is DLOG
-8191. If you examine DITL (dialog item list) -8192, you'll see only placeholders
where the paper sizes appear in the style dialog.
At least with respect to Imagewriter paper sizes, it is possible to make some
changes. The PREC 3 resource in the Imagewriter file specifies the names of the
papers as they will appear in the style dialog, and the sizes of the paper. The format of
the PREC 3 resource is as follows:
n [1-word count] -- number of paper sizes;
n pairs of words -- vertical,horizontal paper size in 120ths of an inch;
n Pascal-format strings -- names of paper sizes;
1 word -- ? (probably flags for Orientation, Pagination, Reduction).
Up to six paper sizes can be accommodated by the style dialog box. The
distributed Imagewriter file PREC 3 resource contains the specifications of five sizes
(US Letter, A4 letter, US Legal, International Fanfold, Computer Paper).
As to other aspects of the dialogs I'm afraid you're on your own; I note the
following warning in IM : "Your application should not change the data in the print
record -- be sure to use only the standard dialogs for setting this information.